Developers have a need to create and/or manage complicated systems that include large numbers of Application Program Interfaces (APIs) that receive high call volume. For example, dozens, hundreds, or more connected APIs may receive millions, billions, or more calls per day.
In a system, an API call may result in API node output that is passed to downstream API nodes. Thus, a single API call may trigger dozens, hundreds, or even more downstream API calls. Often, the routing pathways that API calls take through a set of nodes may be unknown or difficult to predict, owing to the complexity of the API system and the customizable nature of API calls. Further, node output from one API may be incompatible with another API, resulting in errors, failures, breakpoints, and other problems that prevent a system from successfully processing an API call. This creates challenges for developers, who may be unable to develop a system that can handle some API calls that the system receives.
Developers have limited tools for testing APIs during production. Typically, testing consists of passing actual or synthetic API calls to API nodes to identify and predict possible break points. This method of testing may be inefficient and consume large quantities of computing resources because APIs are often running. This method may also require a high degree of human oversight to generate and monitor tests. Further, problems may go unidentified and undetected until APIs are released and actual API calls trigger errors.
Therefore, in view of the shortcomings and problems with conventional approaches to training models, there is a need for efficient, unconventional systems that identify problems with API systems.